The MPI standard define the name for all predefined datatypes, and MPI_DATATYPE_NULL is part of that group. Thus, I see no reason for the current in MPI_TYPE_GET_NAME that prevents the retrieval of its name.

I guess I'm a little confused. Can you cite where in MPI-4.0 it says that invalid handles such as MPI_DATATYPE_NULL should have a name returned from MPI_TYPE_GET_NAME? The only description I see under MPI_TYPE_GET_NAME (MPI-4.0 p385:23-24) says:

Named predefined datatypes have the default names of the datatype name. For example, MPI_WCHAR has the default name of "MPI_WCHAR".

It doesn't say that invalid handles are accepted by MPI_TYPE_GET_NAME. What am I missing?

MPI_DATATYPE_NULL is not an invalid datatype, it is a NULL handle, and as such it is a predefined constant. Thus, I believe that the naming rule cited above applies.

Forcing a library writer to check for MPI_DATATYPE_NULL before calling MPI_TYPE_GET_NAME is as sensical having printf not allowing the printing of NULL pointers.

The other get_name functions do not suffer from the same problem. This PR is good to be merged.

The other get_name functions do not suffer from the same problem. This PR is good to be merged.

Yes they do. MPI_COMM_GET_NAME calls:

which is

which explicitly checks for MPI_COMM_NULL. There's a lengthy comment there explaining that there is ambiguity about MPI_COMM_NULL -- it is "invalid" or is it just a NULL (but valid) handle? It looks like that issue has not been resolved in the MPI standard.

Additionally, MPI_WIN_GET_NAME invokes ompi_win_invald():

which is

and explicitly checks for MPI_WIN_NULL.

Just to be 100% sure, I tested this with a trivial program:

#include <stdio.h>
#include <mpi.h>

int main()
{
    int len;
    char name[MPI_MAX_OBJECT_NAME];

    MPI_Init(NULL, NULL);
#if 0
    MPI_Type_get_name(MPI_DATATYPE_NULL, name, &len);
#elif 0
    MPI_Comm_get_name(MPI_COMM_NULL, name, &len);
#else
    MPI_Win_get_name(MPI_WIN_NULL, name, &len);
#endif
    printf("Got name: %s\n", name);
    MPI_Finalize();
    return 0;
}

I ran it with all 3 possibilities and Open MPI -- and MPICH 4.0 -- generate an error for all 3 MPI_*_GET_NAME with MPI_*_NULL cases.

Given that there is some ambiguity here, I think we should have the same behavior for all of the MPI_*_GET_NAME functions: they should all either accept the MPI_*_NULL handles or they should all disallow the MPI_*_NULL handles. Currently, they do the latter. If we want to change to the former, that's probably fine, but a) we should be consistent, and b) we should probably also document this behavior.

@bosilca if you fix up all the MPI_*_GET_NAME functions, I'll fix up the docs.

Our implementation of ompi_*_invalid is, well, invalid. There is a lengthy comment in communicator.h on why we're doing the wrong thing (according to MPI 2.0), but we're fine with it because we have implemented shortcuts in the few places where it was needed (basically f2c and c2f functions). Anyway, if we assume that invalid means, improper for communications, then we should be good for now.

I disagree with this PR. I think our current behavior is required by the standard and don't believe we should commit this without clarification from the MPI Forum. I think this is the desired behavior, but I also believe it violates the MPI standard (meaning we shouldn't do it without clarification on the standard).

MPI_COMM_GET_NAME (and friends) operate on a communicator. MPI_COMM_NULL is not a communicator; it's the NULL handle. The first sentence of MPI_COMM_GET_NAME is:

MPI_COMM_GET_NAME returns the last name which has previously been associated 22 with the given communicator.

Unless we all agree that you can call MPI_COMM_SET_NAME on MPI_COMM_NULL, and I would claim that the definition of MPI_COMM_SET_NAME:

MPI_COMM_SET_NAME allows a user to associate a name string with a communicator.

prohibits calling SET_NAME on MPI_COMM_NULL because, again, MPI_COMM_NULL is not a communicator, then we can't have GET_NAME handle the NULL handles and conform to the MPI specification.

The bit in MPI_COMM_GET_NAME about predefined communicators is also not ambiguous today. It says:

The three predefined communicators will have predefined names associated with them. Thus, the names of MPI_COMM_WORLD, MPI_COMM_SELF, and the communicator returned by MPI_COMM_GET_PARENT (if not MPI_COMM_NULL) will have the default of 35 "MPI_COMM_WORLD", "MPI_COMM_SELF", and "MPI_COMM_PARENT".

Note (1) the explicit callout of MPI_COMM_NULL as an exception and (2) that it says predefined communicators, not predefined communicator handles. Again, MPI_COMM_NULL is not a communicator, so this section would not apply.

The same argument applies to the invalid/valid flag. MPI_COMM_NULL is not a valid communicator, because it isn't a communicator. At one point, we used to mark objects (comm, win, etc.) invalid once they were freed, because the pointer to them was still "valid", from the sense that nothing prohibited a caller from using that pointer to a MPI_Send and it was likely still valid memory full of a semi-sane looking communicator that wouldn't actually work. George's comment makes me think that code got removed at some point. But I don't think removing the invalid is the right choice here, either.

Rescinded my review based on further MPI standard evidence presented above.

Rescinded my review based on further MPI standard evidence presented above.

@gpaulsen Did you look at mpi-forum/mpi-issues#544?

@jsquyres @bosilca Could you please move forward this PR?

Note that #13276 fixed MPI_Comm_get_name.

MPI_Win_get_name should be fixed, too. Do you prefer to rebase the changes in this PR and do everything here?
Or would it be better to close this PR and start fresh with a new one?

Once rebased this shows little difference with main. I checked with the example above and all NULL objects return the correct name with main, this PR is unnecessary.